1. Field of the Invention
The present invention relates to tools for software development. In particular, the present invention relates to a tool for developing real time systems.
2. Discussion of the Related Art
In a typical real time system, the central processing unit (CPU) performs a number of response time-critical tasks under a schedule controlled by a kernel of a real time operating system (RTOS). Under the schedule, each task is allocated a limited amount (“slice”) of time, so that no single task can hoard the CPU—a scarce resource—to the detriment of other tasks. The time allocated to a given task can vary according to an assigned priority of the task. Kernels of RTOS's are available commercially from a number of vendors.
FIG. 1 is a block diagram of a real time operating system 100. As shown in FIG. 1, RTOS 100 includes kernel 101 which controls the scheduling of a number of tasks 102-106 through interfaces 107-111, respectively. An example of a task is an interrupt service routine for handling an interrupt from a peripheral hardware device. Interfaces 107-111 are each a small program section of the task which communicates with “hooks” in kernel 101. Naturally, interfaces 107-111 conform to the interface requirements of RTOS 100. Kernel 101 allocates time slices and assigns a priority to each task, and activates or deactivates a task through the associated interface according to the time slices and the priority assigned. For example, kernel 101 ensures that an interrupt service task begins execution within a predetermined maximum latency from an interrupt. Kernel 101 is also responsible for such “house-keeping” tasks as garbage collection and prevention of deadlocks (i.e., two or more tasks waiting for each other to complete executing, resulting in none of the tasks being able to proceed).
An alternative to managing the schedule from commercially available kernel 101 is a task management scheme that is illustrated by polling loop 200 shown in FIG. 2. Polling loop 200 is typically created by a system programmer for a specific application.
To implement polling loop 200, the system programmer provides “task management” task 201 and task management code included in the program code of each of interface 207-211 of tasks 202-206. Typically, scheduling using a polling loop is simpler than that provided in kernel 101 and thus requires less memory space for task management. Further, since only the necessary task management code needs to be included in interfaces 207-211, the bulkiness of a generic driver suitable for use with many tasks is avoided. Consequently, a polling loop is both memory-space efficient and easier to debug, and typically provides a shorter response time. However, timing in a polling loop is less predictable than the kernel approach, and the management code that is necessary in each task interface is written in each instance by the system programmer implementing the polling loop. Unlike an RTOS kernel, which is available commercially in debugged form and supported with service and upgrades, the polling loop must be maintained by the system programmer, including the code for performing housing-keeping tasks and preventing deadlocks.